IBIS Macromodel Task Group Meeting date: 29 September 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Michael to send a third draft of the [Clock Pins] BIRD proposal. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 22 meeting. Bob noted that his comments with respect to a "rail specification" should have been recorded as RAIL (Rules Augmented Interconnect Layout) specification. Since the minutes had not yet been uploaded to the ATM minutes page on the IBIS website, Curtis took an AR to send out an amended version. Randy moved to approve the amended minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: Topic Bin List: Arpad noted that he had removed the "IBIS-ISS parser" entry in the topic bin list, as Randy had earlier suggested. This topic has been taken up by the Interconnect task group. New Clock-Data Pin relationship BIRD [Clock Pins]: Michael Mirmak briefly summarized the third draft of the [Clock Pins] BIRD, which he had sent out prior to the meeting. Based on concerns expressed about not fully defining the timing relationship entries in column 3, he had removed column 3 altogether. There are now two columns. The first column must contain a clock pin, and the second column contains a data or clock pin. This draft no longer mentions the possibility of a third column. Ambrish noted that the second column could contain a data or clock pin, but he observed that the second column Sub-Param was called "data_pins". Michael agreed that this was an inconsistency and asked for other suggestions for the name. Ambrish suggested "clocked_pins". Michael agreed with this suggestion, and no one objected. Bob said he would prefer that we kept the third column and its placeholder values if we ever have any intention of adding it later. He said adding new columns to the keyword later gets messy. If we don't have the third column now, then this keyword should be limited to stating a relationship between two pins, and we should not plan on extending it later. Ambrish asked if Bob considered the BIRD incomplete with only two columns. Bob said he did consider it incomplete if we had a BIRD with the expectation of having to add more columns to the keyword later. Bob said that if we really get into timing relationships it gets complicated quickly. The RAIL specification, for example, had gone into all sorts of combinations of rising edge, falling edge, etc. This would likely be too much to include with this keyword, so the third column could ultimately just point to a new keyword (new BIRD) that would be needed to define the timing relationships. Bob preferred that we keep a third column with some defined value(s) that we knew would be useful later. Michael reiterated that his primary goal was to capture the clock pin to data pin relationship envisioned by recent BIRDs like BIRD204 and BIRD207. However, there is more information that will ultimately be needed. He said the third column could provide information analogous to Vinl and Vinh, for example. You need to give the user/tool enough information to know if their timing is outside of design requirements. His fear was that it would be a long arduous process to iron out the details of any definitions in column 3, but if we didn't have this BIRD at all then we may end up with no easy way to add the basic relationship information later. Michael noted that Arpad had asked for more information on the values in column 3 at the previous meeting. He asked Arpad if he preferred two columns or three. Arpad asked if there was really much of a difference between two columns and three columns if the third column contained a non-functional placeholder. Bob said there were parser implications and forward-compatibility complications with adding a column later. Ambrish asked if we could populate the third column with "placeholder" or some other string to avoid the confusion of attempting to specify more meaningful names at this point. Michael said that it might be strange to draft a proposal with a third column that is essentially for future expansion, but he was okay with it. He said he thought that the third column might eventually refer to a new keyword, or perhaps to a file, containing the additional information. The group discussed several possible placeholder values. NA (not applicable) was seen as confusing. Michael suggested the string "unspecified". No one objected. Bob noted that this would be a case-sensitive string comparison, as it is not a reserved word or keyword. Bob suggested a careful review of the language associated with Series models. He noted language regarding "prohibited Model_types" Series, Series_switch, and Terminator and another section stating [Clock Pins] is "not compatible" with [Series Switch Groups] or [Series Pin Mapping]. He said we may need to explicitly state that certain combinations are illegal. Bob said the proposal's language, which excluded pins appearing in column 2 from appearing on more than one line, was blocking a legal configuration such as a clock tree made up of I/O elements in which the clock-data relationship between two pins could go in either direction. Arpad asked if the question from Bob and Fangyi the previous week about a pin appearing as the clock pin on one line and the data pin on another had been resolved. Michael referred to this sentence in Usage Rules: Entries in the second column shall not appear on more than one line under the keyword. He said it prohibited all of these scenarios. However, he removed the rule in order to relax the restriction. He said the rule was compatible with DDR applications, but removing it opens up the possibility of supporting other topologies like Bob had described. He said removing the rule made it impossible for the parser to catch some illegal combinations in the DDR context unless we were to add additional rules for each specific application. Michael gave himself an AR to create a fourth draft of the BIRD with these changes from the meeting discussion: - Add a third column with "unspecified" as the entries. - Remove the restriction on entries in the second column appearing on other lines. - Address additional editorial comments Bob would send to him. - Curtis: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. AR: Curtis to send amended minutes from the previous meeting. AR: Michael to create a fourth draft of the [Clock Pins] BIRD proposal. ------------- Next meeting: 06 October 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives